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Planning for computer-based tools to help in the measurement and analysis 
of network traffic data began in the late 1960s. During this same period, the 
rapid introduction of computer technology was changing the character of the 
network. The network was becoming more efficient and economical but, at 
the same time, more sophisticated and complex. This intensified the need to 
provide timely and complete information to those responsible for the manage- 
ment, administration, engineering, and planning of the network. The com- 
puter-based systems that were developed to meet this need are collectively 
called the Total Network Data System (TNDS). This paper discusses the 
operating environments of the network and telephone company, and provides 
a framework for the remainder of the papers in this issue. 

I. INTRODUCTION 

Managing, engineering, and planning the telecommunications net- 
work are essential tasks for the future health and vitality of the 
network. These complex tasks cannot be performed effectively without 
detailed data about network traffic. The Bell System has mechanized 
the collection and processing of such data with a family of computer- 
based systems collectively called the Total Network Data System 
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(TNDS). This paper provides an overview of the telecommunications 
network environment, introduces the need for network traffic data in 
the operating environment of the telephone company, and briefly 
discusses the primary mechanization objectives for collecting and 
processing the network traffic data through the TNDS. 

II. THE TELECOMMUNICATIONS ENVIRONMENT 

To appreciate the need for network traffic data, it is necessary to 
have a general understanding of the telecommunications network. 

2. 1 Network description 

In the most general sense, a network can be defined as a set of nodes 
interconnected with links. We can further define the telecommunica- 
tions network (hereafter referred to as "the network") both on the 
basis of its function and its physical characteristics. From a functional 
standpoint, the network carries a variety of telecommunications traffic 
(e.g., voice, data) between a number of stations that can be connected 
on demand, or that are permanently connected. From the physical 
standpoint, the network consists of switching systems (nodes), trans- 
mission facilities (links), and stations (sources and receptors of traffic) 
that are connected together in an organized and controlled manner. 
These two views are complementary and together provide a framework 
for understanding aspects of telephone engineering and operations. 1 

Let us examine the physical elements of the network more closely. 
To construct a telecommunications network that would allow com- 
plete, direct interconnection of all stations would be both impractical 
and cost prohibitive. Therefore, every large communications network 
is based on the principle of shared facilities, whereby facilities that 
can be shared among different elements of traffic are utilized exten- 
sively when designing and building the network. Central offices are 
entities built to provide switchable interconnection of customer sta- 
tions. A central office allows each of its customers, with a single pair 
of wires connected to the office (i.e., the customer's loop facilities), to 
talk to any other customer served by that office. Such a central office, 
having customer station equipment directly connected to it, is said to 
serve "local" traffic from those stations. 

In general, however, customer stations being connected are served 
by different central offices. Therefore, central offices are connected to 
one another by transmission paths called trunks, so that customers in 
one office can reach customers in another. The network of trunks 
interconnecting central offices is referred to as the Interoffice Facility 
Network. To enable all stations in the network to be interconnectable 
while making efficient use of network equipment and facilities, switch- 
ing and trunking arrangements employ a hierarchical network config- 
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uration and the principle of automatic alternate routing. 1 [A new 
traffic routing technique called Dynamic Non-Hierarchical Routing 
(DNHR), planned for deployment in the intercity network beginning 
in 1984, promises significant cost savings in the network.] 

The hierarchical network configuration provides for the collection 
and distribution of traffic and permits switching systems to be com- 
pletely interconnectable. The hierarchical aspect prevents "loop 
arounds" that might otherwise occur when calls are automatically 
alternate routed through the network. Each switching system is given 
one of five classifications based on the highest switching function 
performed within the hierarchy, its interrelationship with other 
switching systems, and its transmission requirements. 

With the automatic alternate routing principle, a call that encoun- 
ters an "all trunks busy" condition in the interoffice facility network 
on the first route tested is automatically offered sequentially to one or 
more alternate routes for completion, if such alternate routes are 
possible for that item of traffic. Arrangements, defined by the Network 
Routing Plan, that dictate the final routing of traffic are called 
"homing arrangements." Central offices whose only function is to 
route calls through the hierarchy are called toll offices. These offices 
do not directly serve customers (i.e., do not have any connecting loop 
facilities). Regional Centers, the switching systems at the top of the 
switching hierarchy, are examples of toll offices. Many central offices 
perform a tandem switching function (i.e., route traffic by simply 
interconnecting interoffice trunk groups). These offices may perform 
a pure tandem switching function or they may also function as local 
or toll switching systems. 

2.2 The concept of service 

Because only a small percentage of telephone customers originate 
calls at any time, the amount of equipment needed to carry the actual 
simultaneous traffic is only a fraction of that needed to carry simul- 
taneous traffic from all customers. If we install a very limited amount 
of equipment, there is no assurance that we can meet service demands 
satisfactorily at all times. Therefore, we can anticipate that a percent- 
age of calls will not be completed (i.e., will be "blocked") during peak 
traffic periods [e.g., during the busiest hour(s) of the day, during the 
busy season (busiest three months) of the year]. When calls are 
"blocked" too frequently, calling customers perceive service as unsat- 
isfactory. Conversely, if we have too much equipment in the network, 
too much of it will remain unused even during peak traffic periods, 
which is not cost effective. 

The proportion of calls blocked during the busy hour of a switching 
system is an index of the grade of service rendered. We define the 
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grade of service as the probability that a certain percentage of calls 
originated during the busy hour will be blocked from utilizing the 
installed equipment and network facilities. There are strong justifi- 
cations for providing a high grade of service (i.e., low probability of 
calls being blocked). For example, when a customer must dial a number 
more than once because of failure to properly connect, it generates 
additional traffic, and during peak periods this further aggravates poor 
service conditions. Acceptable service levels are determined by analyz- 
ing both network traffic data and customer reactions. 2 Objective grades 
of service, or service objectives, are established to balance customer 
service and network cost. It is the effort to strike a cost-effective 
balance between providing service and utilizing network equipment 
that imposes the need for network traffic data. 

2.3 Requirements for network data 

There are four key network functions that require network traffic 
data: network management, network administration, network design, 
and long-range network planning. The function of network manage- 
ment is to control network traffic overloads by distributing loads 
among circuits and equipment to meet customer service demands in a 
way that is best from a total network viewpoint. To do this, network 
management requires a near-real-time view of the traffic in the net- 
work. This is made possible through analysis of network traffic data. 

The function of network administration is to control the assignment 
of lines and trunks to take maximum advantage of the installed 
equipment in the central office for serving the offered call traffic. This 
involves implementing a plan to spread the office load efficiently over 
all equipment, as well as to monitor the current load, service levels, 
and office capacities. A major task within network administration is 
to use traffic data to monitor the flow of traffic through the central 
office and to detect changes in office performance (e.g., service deg- 
radation) or in offered load. Network administration includes the task 
of providing sufficient, accurate network traffic data for all functions. 

The function of network design is to estimate where, when, and how 
much equipment will be required within a five-year period so that the 
necessary additional equipment (i.e., relief equipment) can be ordered 
and installed in time to satisfy the service objectives. 4 This activity 
requires data that reflect traffic volumes being carried by existing 
equipment, as well as knowledge of equipment capacities. 

The function of long-range network planning is to determine the 
most economic growth and replacement strategies for the network to 
meet estimates of future demand. This future demand is estimated 
using current traffic load trends and marketing information. The basic 
output of this function is a broad view of network topology 20 years 
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into the future. Section 3.3 further discusses these key network func- 
tions relative to telephone company operations. 

In addition to the network functions discussed above, the Bell 
Operating Company (BOC) marketing organizations request network 
traffic data to aid in the administration and provisioning of each 
individual customer's telecommunications service. Due to such factors 
as increased availability of Stored Program Control (SPC) features 
and vertical services, increased data sophistication of subscribers and 
increasing competitive pressures, the number and frequency of these 
traffic data requests have been increasing consistently. Regulatory 
needs for these data have also appeared. For example, to support 
requests for rate increases before regulatory bodies, the BOCs conduct 
very detailed traffic studies. Regulatory study data requests tend to be 
complex and difficult to anticipate. These marketing and regulatory 
needs are only examples of a growing family of special applications 
that require network traffic data. Though they don't constitute a basic 
network function, they do represent a significant environmental ele- 
ment that must be considered when planning for the collection and 
processing of traffic data. 

Another function requiring traffic data is operator services force 
administration. This function involves forecasting the load that will 
be offered in each half-hour and determining the operator force nec- 
essary to carry that load at an objective grade of service. This requires 
data on traffic volumes, service, and force levels. Because this function 
has limited interaction with the above-defined key network functions, 
its data tend to follow a separate but somewhat parallel flow that will 
not be discussed in this article. 

2.4 Network data 

The fundamental types of traffic measurements include: 

1. Event counts— These measurements simply represent the num- 
ber of occurrences of an event that occurred in a specific time interval 
(e.g., hour ending 11:00). "Offered" calls are termed peg counts, while 
"blocked" calls are termed overflow counts. 

2. Usage — These measurements represent the estimated amount of 
time an equipment component was busy during a specific time interval, 
generally an hour. In electromechanical (EM) switching systems, usage 
is typically obtained through a separate, special measuring device, the 
Traffic Usage Recorder (TUR). In SPC switching systems, usage 
measurements (as well as the others) are generated internally by the 
switch. 

3. Delay — This type of measurement usually indicates, on the av- 
erage, how long a particular type of event would have been delayed, 
say by an all-servers-busy condition, if it had chosen to wait. Some 

TNDS ENVIRONMENT 2131 



different measures of delay include: average delay, average delay of 
events delayed, probability of delay, and probability of delay exceeding 
some specified time interval. 

4. Status — This measurement, used for network management and 
administration, indicates the presence or absence of a condition (e.g., 
equipment outage, severe overload) and is usually in the form of a 
lamp indication. 

With few exceptions, measurements are made at the location of the 
switching system. All switches make some traffic measurements inter- 
nally. The interfaces for data collection from EM systems are traffic 
register leads for peg count, overflow, grouped usage and delay, as well 
as status-indicating leads. In the case of EM systems, it is usually 
necessary to provide special traffic measurement equipment (e.g., the 
TUR) at the switch location. This equipment, in conjunction with 
special software in the data collection machine, makes possible the 
gathering of more detailed individual circuit usage data rather than 
circuit group data. This concept, used for selected EM offices to help 
increase data accuracy, is called Individual Circuit Usage Recording 
(ICUR). For SPC switching systems, traffic measurements and status 
indications are collected by the basic internal programs. The infor- 
mation, equivalent to that stored in EM registers, is retained in 
memory until the accumulated results are read out on schedules 
established by the users. 4 

In the Bell System, the volume of network traffic data processed is 
overwhelming. It was estimated that in the average BOC, over 50 
million pieces of traffic data per week were collected and processed in 
1980 to support the management, administration, design, and long- 
range planning of the network. 3 Because of the size, complexity, and 
importance of the network data job, the management of the data has 
become a major internal function of the BOCs. 

Next we discuss another fundamental element of the network data 
system environment — the BOC operational environment. 

3. THE OPERATIONAL ENVIRONMENT 
3. 1 Operations planning 

Planning for modern computer-based tools to help in the measure- 
ment and analysis of network data began in the late 1960s. During 
this same period, the rapid introduction of computer technology was 
changing the character of the network. The network was becoming 
more efficient and economical but, at the same time, more sophisti- 
cated and complex. The people responsible for the network's day-to- 
day operation (i.e., management, administration, engineering and 
planning) needed more timely and complete information. Bell System 
management recognized that the largely manual methods in use during 
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the 1960s could not keep pace with the emerging operational needs of 
the 1970s and 1980s. 

Three properties of network data made the planning of computer- 
based support tools particularly challenging. 

1. The data are almost useless until they are processed. 

2. A much larger volume of data must be gathered than will be used 
ultimately because of the way that data are generated and output by 
the SPC switch and the external measurement devices of the EM 

switch. 

3. The same basic data must be summarized in varying ways to 
meet the needs of a diverse family of users (see Section 3.3). 

Measurement, data processing, and user applications must, there- 
fore, be considered together in planning for the mechanization of an 
"end-to-end" flow of data. 

The formulation of such an end-to-end view of the data flow requires 
an understanding of the functions performed by various work groups 
and how these groups relate to one another. This allows the formula- 
tion of requirements that describe how the work groups can best be 
supported by computer-based tools. Finally, the tools must be related 
to one another and to the elements of the telecommunications network. 
This concept of a process view, encompassing functions to be per- 
formed by people and computers, has been one of the principles used 
in the design of the individual components, termed Operations Systems 
(OSs), that comprise the Total Network Data System (TNDS). 4 

This view of the overall data flow not only facilitated the allocation 
of functions to the specific TNDS-related OSs, but also resulted in 
the identification of functions that must be performed by people. 
Consequently, work groups, termed operations centers, were estab- 
lished to oversee the operation of the elements of TNDS and ensure 
the integrity of the process. The allocation of functions among people 
and computers, together with a specification of how they interact to 
accomplish an overall process, was among the initial efforts in a 
general discipline known as operations planning. 

Since then, the concept of operations planning has been expanded 
to encompass virtually all areas of telephone company operations. It 
is an organized, disciplined procedure to provide an integrated opera- 
tions structure. This, in turn, will permit the Bell System to meet 
customer and market needs while minimizing the operational cost 
through applied computer technology. These efforts have produced a 
family of operations plans that guide AT&T, Bell Laboratories, and 
the telephone companies in the planning and deployment of the over 
100 currently available OSs. 5 

Planning for the evolution of the network data collection process is 
now one element of an overall plan known as the Total Network 
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Operations Plan (TNOP). The planning process is not static; efforts 
are now under way to define the directions in which operations centers, 
systems, and processes should evolve to meet the future needs of the 
telecommunication network and the people who operate it. 

3.2 Modeling the environment 

A key factor that influences the plan for mechanized support of the 
network traffic data acquisition and analysis process is the telephone 
company operating environment. We can gain insight into the require- 
ments imposed by this environment by analyzing models that repre- 
sent typical situations and by conducting detailed field studies and 
experiments. These types of activities ensure that both the operations 
strategy and the operations system developments meet the needs 
imposed by both the evolving telecommunications and operations 
environments. 

Many existing operating areas in the Bell System have similar 
characteristics and face similar network operations requirements. 
Thus, four basic types of model areas can be constructed to represent 
the various geographies, populations, and network equipment config- 
urations that presently exist in the Bell System. 

One, termed Model Area II, represents a large, densely populated 
metropolitan region, such as Detroit or Cleveland, with about two 
million main stations. Another, Model Area III, characterizes a state 
or portion of a large state containing over one million main stations 
and having an urban center with over two hundred thousand main 
stations. Indiana and Georgia resemble this model. Figure 1 shows 
maps of the geographic distribution of local switching equipment and 
key line operations centers in these two model environments. Table I 
shows a summary of physical plant statistics in each model environ- 
ment. Of the two remaining models, Model Area IV characterizes 
large, primarily rural states, while Model Area I describes New York 
City and its immediate vicinity. 

While line operations functions can be reasonably studied on an 
area basis, the span of other operations functions, such as trunking 
network design, often covers more than one operating area. Hence, 
the model areas were combined to form model BOCs. Figure 2 illus- 
trates the typical deployment of selected operation functions for one 
such model company. It consists of one Model Area II and one Model 
Area III and resembles a single-state company like the Illinois Bell 
Telephone Company. Similarly, model companies can be combined to 
form a model territory to study toll operations. 

These models provide a basis for quantitatively evaluating the 
effect(s) of the environment on alternative mechanization strategies. 
Among the key elements that influence the design and evolution of 
network data mechanization are: 
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Table I — Physical plant statistics in two model areas 





Model Area II 


Model Area III 




(1.93M Main Stations) 


(1.39M Main Stations) 






Main Sta- 




Main Sta- 




No. of 


tions 


No. of 


tions 




Entities 


(1000's) 


Entities 


(1000's) 


Local switching 










No. 1 Crossbar 


9 


189 








No. 5 Crossbar 


65 


738 


37 


450 


Step-by-Step 


14 


28 


89 


281 


I ESS* 


42 


904 


21 


542 


2 ESS 


13 


65 


15 


97 


3 ESS 


3 


6 


9 


18 


RSS 1 








3 


2 


DCO 2 














DRSS 3 














Total local entities: 


146 




174 




Wire centers: 


98 




159 




Toll and local tandem 










switching 










4 ESS 


1 




1 




I ESS 4 


— 




6 




No. 4A Crossbar 


3 




2 




Crossbar Tandem 


5 




1 




No. 5 Crossbar with 


3 




6 




tandem features 4 










SXS with tandem 4 fea- 


— 




7 




tures 










Trunks (1000's) 56 


162 




118 




Special Service circuits 


114 




80 




(1000's) 6 










T-Carrier channels 


165 




101 




(1000's) 6 










N-Carrier channels 


— 




16 




(1000's) 6 










High-Capacity Carrier 


21 




26 




channels (1000's) 6 ' 7 











1. Remote Switching System. 

2. Digital Central Office. 

3. Digital Remote Switching System. 

4. Local switches with toll or tandem features are included in local entity count. 

5. Interoffice circuits. Intraoffice circuits are not included. 

6. Count includes intra-area plus one-half interarea circuits. 

7. Includes low-capacity carrier systems multiplexed directly to broadband carrier. 
* Trademark of Western Electric. 



1. Number, type, and geographic distribution of data sources (i.e., 
switching systems) 

2. The relative scope, number, and geographic distribution of op- 
erations centers that require mechanized support. 

These factors, together with the nature of the functions performed 
by the various operations centers (see Section 3.3) and insights gained 
through detailed field studies, form the foundation for a network 
traffic data mechanization plan for the 1980s. Section 3.3 discusses 
the key network traffic functions in the BOCs. 
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3.3 Managing, engineering, and planning the network 

The BOC operations centers are responsible for network manage- 
ment, network administration, network design, and long-range plan- 
ning. This section describes how the centers interact and how the 
information flow among centers is managed. 

3.3. 1 BOC Operations Centers 

3.3.1.1 Network management. The Network Management Center 
(NMC) keeps the network operating efficiently when unusual traffic 
patterns or equipment failures would otherwise result in congestion. 
The NMC analyzes network performance and prepares contingency 
plans for situations such as peak days, telethons, and major switching 
system failures. The NMC also routinely monitors near-real-time 
network performance data to identify abnormal situations. Once an 
abnormal situation is detected, appropriate network management con- 
trols are implemented. When the critical situation has passed, the 
network management controls are removed. For further details, see 
the papers entitled "Network Management" and "National Network 
Management" later in this issue of the Journal. 

3.3.1.2 Network administration. The Circuit Administration Center 
(CAC) and the Network Administration Center (NAC) perform net- 
work administration. The NAC is responsible for optimum loading, 
balancing, and utilization of installed central office equipment. It 
performs daily surveillance of central office and connecting trunk 
groups to ensure that service objectives are being met. In addition, the 
NAC reviews profiles of office load relative to profiles of anticipated 
capacity growth. It initiates corrective actions to deal with current as 
well as potential service problems by working with the Network 
Switching Engineering Center (NSEC) to initiate work orders to 
increase equipment in service (Section 3.3.1.3). 

The CAC ensures that in-service trunks meet current as well as 
anticipated customer demands at acceptable levels of service. There 
are two activities, planned and demand servicing, that the CAC 
performs to discharge this responsibility. In planned servicing, the 
CAC compares current traffic loads with the forecasted loads for the 
upcoming busy season. If the loads are consistent, the CAC issues the 
orders to provide the forecasted trunks. When inconsistencies are 
found, the CAC examines the variation, develops a modified forecast 
for the busy season, and issues orders (if appropriate) based on the 
new forecast. In demand servicing, the CAC reviews weekly traffic 
data to identify trunk groups that imminently need augmenting be- 
yond what the forecast states, and issues the appropriate trunk orders. 

3.3. 1.3 Network design. The network design function is performed by 
the CAC and NSEC work centers. The CAC projects current traffic 
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loads for a one- to five-year period based on estimates of main station 
and call rate growth trends, and also develops corresponding forecasts 
of network trunk requirements. The NSEC is responsible for devel- 
oping an analogous forecast of loads for traffic-sensitive switching 
equipment, setting office capacities, and determining relief size and 
timing. 

The forecasts developed specify the amount of equipment (switching 
and trunking) that will be needed for the busy seasons of each of the 
next few years. Based on these forecasts, construction budget dollars 
are committed. The CAC and NSEC ensure that these forecasts are 
consistent with long-range planning. 

3.3.1.4 Long-range planning. Long-range network planning is per- 
formed by work centers such as the Traffic Network Planning Center 
(TNPC) and the Wire Center Planning Center (WCPC). 

The TNPC conducts studies to determine the most economic growth 
and replacement strategies for the network to meet its estimates of 
future demand. The estimates of future demand are based on current 
traffic load trends and marketing information. The plans developed 
start with the present environment and provide corporate guidance 
for future network configurations over a 20-year period. This planning 
process includes the tandem switching systems, operator services 
networks, trunks interconnecting all switching systems, and switching 
terminations to accommodate the trunks. 

The WCPC conducts similar studies for the local wire center areas. 
The WCPC planning process includes the local switch and its inter- 
action with other network elements (such as the subscriber network 
and interoffice facility network). 

The basic output of the long-range planning function is a broad 
view of the future network topology. This includes the numbers, types, 
and locations of switching systems and the homing arrangements. The 
resulting long-range plan embodies various routing rules, such as 
whether local and toll traffic will flow through the same tandems in a 
metropolitan network and what sequences of alternate routes will be 
used. Such planning does not involve commitments to spend money 
but rather to ensure that the long-term consequences of current 
decisions are foreseen and that the evolution of the network proceeds 
smoothly and economically. 

3.3.2 Work center interrelationships 

Figure 3 illustrates how these work centers interact to perform 
network management, network administration, network design, and 
long-range planning. 6 

The TNPC and WCPC provide the CAC and NSEC with the 
fundamental office and network evolution plans (20-year horizon). 
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The CAC and NSEC review current trends in traffic offered to in- 
service network and switching equipment. They develop forecasts of 
specific equipment needs for the next one to five years, consistent 
with the fundamental plans. The forecasts result in construction 
budget allocations and equipment orders. 

The CAC and NAC review the current level of traffic offered to in- 
service equipment. The CAC and NAC identify current (within a year) 
equipment rearrangement and growth needs. Accordingly, equipment 
is rearranged, ordered, and installed. 

The NMC, with the help of the CAC and NAC, prepares contingency 
plans for situations such as peak days, telethons, and major switching 
system outages. The NMC routinely monitors the load, in near- real 
time, to identify unusual traffic patterns and equipment failures that 
have resulted or will result in congestion. The NMC will implement 
the network management plans, as required, to deal with the problems. 

As an example of the interrelationships of these centers, Table II 
outlines the role of the NMC, NAC, and CAC relative to the surveil- 
lance of network service. The primary differences that can be noted 
are: the time frame of interest and action, the geographic domain 
(network), and the network components of interest. 



Table II — Summary of relative service surveillance roles in BOC 
Operations Centers 



Center 



Surveillance Objective 



Network Traffic Data Used 



Network Manage- 
ment Center 



Network Admin- 
istration Center 



Circuit Adminis- 
tration Center 



Monitors traffic congestion in a 
portion of the network (e.g., a 
numbering plan area) and ini- 
tiates controls to maximize 
call completion during times of 
overload or equipment failure 

Monitors load and service status 
for each switching system and 
its trunk groups in a central 
office district, determines if 
service objectives are being 
met, detects or is informed of 
potential or actual service-af- 
fecting problems, initiates cor- 
rective action when necessary, 
and verifies that problems are 
being resolved 

Monitors traffic loads on the 
message trunk network in an 
operating area or company, de- 
termines the need for near- 
term trunking rearrangements 
and additions to resolve condi- 
tions that are network service- 
affecting and that are expected 
to persist 



5- to 20-minute traffic data 
and 30-second network 
status data for selected 
central office equipment 
and trunk groups in se- 
lected central offices 

Hourly and weekly central 
office equipment and 
trunk group traffic data 
and selected status indi- 
cators 



Weekly and longer-term 
summaries of trunk group 
traffic data 
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3.3.3 Management of information flow 

Coordinating the flow of information to and among the work centers 
is a complex task for which work centers have been established. The 
Network Data Collection Center (NDCC) coordinates schedules and 
ensures that the requested data are collected and distributed appro- 
priately (i.e., in the most timely and cost-effective manner). Operations 
systems have been developed for internal operations and information 
exchange. The NDCC coordinates the execution of these systems on 
a day-to-day basis. 

Up to this point, we have discussed the network and the BOC 
operational environment. Now let us turn our attention to the func- 
tional objectives of a data system to mechanize the network data 
process. 

IV. MECHANIZATION OBJECTIVES 

Until the early 1970s, the collection and processing of network 
traffic data by the BOCs was a combination of manual and semi- 
mechanized processes. A number of environmental changes made this 
type of network data environment inadequate to meet the needs of 
the business. These influences included: 

1. Growing sophistication and complexity in an increasingly SPC 
network 

2. Need for immediate information for network management and 
for more complete and timely information for all network-related 
functions 

3. Increasing regulatory and competitive pressures. 
Accordingly, the trend was toward mechanizing the network data 

process. The overall objective of this effort has been to automate the 
process of collecting and summarizing network traffic data so that 
BOC decision makers have adequate quantities of timely and accurate 
information to administer and engineer the network. To be effective, 
the system must be robust to varying BOC environments (e.g., orga- 
nizational responsibilities, mechanization deployment) and must be 
expandable to meet the growing processing needs of the BOCs. The 
system must offer a manageable and cost-effective implementation for 
the BOCs in the context of their operations. 

Before describing the implementation of the Bell System's com- 
puter-based network data system, let us look at the basic data function 
objectives that such a system must meet to satisfy the needs of users 
performing key BOC traffic functions. 

4. 1 Data collection 

After the traffic measurements have been taken by the switching 
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system or by special measurement equipment located near the switch, 
it is desirable to collect the measurements at a centralized location 
where large-scale data processing can be brought to bear. The system 
must be capable of collecting network traffic data from all types of 
switching entities — EM and SPC systems, local, tandem, and toll 
switches. 

Because the equipment collecting the data is centralized and has 
access to the switching systems it serves, it is practical to delegate 
measurement control (e.g., turning on a TUR to begin taking mea- 
surements on the basis of a collection schedule) and network manage- 
ment control (e.g., signaling to a switching system to cancel alternate 
routing) to the same collection equipment. 4 

4.2 Data administration 

The system must also support a number of "data administration" 
activities. Measurements to be collected from switching systems must 
be scheduled so they are not collected during periods when they are 
not required (e.g., during low traffic periods). In addition, the system 
must allow users to control the data processing schedules (e.g., hours 
of the day for which the data collected are to be summarized into the 
various reports). 

The measurements must also be linked to records that associate 
each measurement with the equipment being measured. In addition, 
records of the individual switching system characteristics (e.g., inven- 
tories of installed central office equipment) must be maintained. No 
less important than the network traffic data, complete and accurate 
records are absolutely required by the system to transform raw traffic 
measurement data into useful information. The generation and main- 
tenance of these records are major tasks that must be supported by 
the system. 

At times, more data are collected than are actually needed due to 
the way measurements are accumulated and "packaged" by the switch 
or by the special measurement equipment. The system should identify 
and remove these unneeded data as early as possible to avoid wasteful 
processing. 

It is necessary for the system to validate data (i.e., inspect them to 
determine if they truly reflect network traffic conditions that they are 
intended to measure) soon after collection to avoid processing incorrect 
data and allowing them to contaminate the associated good data. 

As a final data administration task, the system must ensure that 
measurement data are distributed as appropriate between the different 
processing elements of the system as well as to any other Operations 
Systems that require those data. 
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4.3 Report generation 

To present BOC users with useful information, the system must 
perform a number of processing and reporting tasks. As Section 3.3 
showed, there are four key traffic-related functions that depend on 
network traffic data. A primary factor in designing a successful net- 
work data system is satisfying the needs of the BOC people performing 
these functions — both in the type of information reported and the 
timeliness with which it is made available. 4 

Reported information should be in formats that allow users to 
quickly identify and interpret the information. The system should 
provide a set of predefined, standard reports as well as capabilities for 
selective, demand query of information to allow users to obtain infor- 
mation in formats customized to their special needs. In addition, the 
system must allow the users to control the routing of processed outputs 
and must be able to deliver processed results to users in the form to 
be used in their local operations (i.e., paper reports, microfiche reports, 
hard copy or cathode ray tube terminals, status board). 

Automatic, more detailed, validation should be performed to aug- 
ment that carried out shortly after data collection. Validation reports 
should be generated to help users detect suspect data. In addition, the 
system must allow users to highlight and exclude information that is 
judged suspect so that it is appropriately treated in affected reports. 

The system should provide access to network information in time 
frames consistent with the spectrum of user functions (see Fig. 3). For 
instance, the system must provide five-minute network load informa- 
tion in an immediate time frame as the basis for real-time management 
of the trunk network. However, the system must summarize and 
maintain information for a year or more to support central office and 
facility engineering and long-range planning. In general, the system 
should store data and results for periods of time based on anticipated 
information usage patterns and economic considerations. 

The system must collect and report information on its performance 
(e.g., data collection availability) to allow the BOCs to promptly 
identify and resolve system performance problems and to otherwise 
manage the system. 

4.4 Robustness 

A mechanized network data system must continue to evolve as new 
switching machines are introduced, as new network services and 
features demand the processing of new measurements, as new provi- 
sioning or network design algorithms are formulated, and as new 
functions arise for the network data system. In addition to simply 
evolving to meet new processing needs, the network data system must 
do so at or near the time of introduction of new technology to help 
minimize the impact on Bell System operations. 
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Fig. 3— Work center interrelationship. 

V. CONCLUSION 

The Bell System has implemented a mechanized process known as 
the Total Network Data System to meet the needs we have outlined. 
This TNDS consists of a set of subsystems, each performing part of 
the overall process. The formulation of and adherence to a system 
plan has helped assure that all parts of TNDS have been available 
when required to support the network management, administration, 
design, and long-range planning needs of the BOCs. The paper that 
follows discusses this "TNDS System Plan" and the component TNDS 
subsystems that have evolved. 
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